not sure we can release directly as 1.0 ? waiting for other maintainers input on this

I would definitely prefer to start with 0.1.0

Should this be warn? I think it's valid. User should be able to install a resource detector and have it working only when relevant IMO.
I suggest differentiating between 2 cases:

1. "no docker" case which should report info and not report the error in the message
2. some unexpected exception was thrown - error and includ the error in the message

So - the reason for this is - if you are installing DockerResourceV1Detector - that would mean - you are adding this dependency assuming you have v1 version running - hence the warning !

As this dependency would be of no use if it did get them the container id - hence we need to warn them that they need have a diff docker version running.

See my comment on the other thread

Same as the previous comment. If the file is missing, I suggest to not log warn since it's valid

We need a way to let the user know that their dockerV1Detector is not doing as they hoped. I am wondering if their a another way - do you have any suggestions ?

I am wondering if including a resource detector means that the user is expecting that resource to be present.

2 Examples:

1. If the user installs an aws detector and then runs his service locally, I wouldn't expect any warnings to be printed to log as this is completely valid and the message will be confusing. Maybe the service is running inside a docker in production but not in other environments.
2. If someone creates a distribution of OpenTelemetry and includes many detectors, the expectation (as far as I am aware) is that only the relevant detectors will be applied. Detectors that are not relevant should be silently ignored. This is the way instrumentations are handled: if someone installs the @opentelemetry/auto-instrumentations-node package with all instrumentations, and then his app does not require redis package, then instrumentation-redis will just not load with no warning to diag channel

I think emitting it as info makes more sense, something like: "Docker CGROUP V1 Detector did not identify running inside a docker container, no docker attributes will be added to resource".

This is for the case that the file does not exist. If the file exists but exception is thrown for any other reason, I would expect an error with message that includes the errorMessage.

This is my take on it, but I'm open for other opinions

Quoting from the DiagLogger interface:

  /**
   * Log a warning scenario to inform the developer of an issues that should be investigated.
   * The requested operation may or may not have succeeded or completed.
   */
  warn: DiagLogFunction;

I think when the file is missing it doesn't mean that the developer should investigate anything but only be informed

This is very helpful - thank you for taking the time and helping me out with this. I appreciate it.
Addressed.

What is the motivation to return an object and not directly an Error?
I did not check but guess the fs functions returns an Error

motivation is to keep it same as implementation where we are return an error obj.

Maybe I misunderstand you, but the test uses:

      const errorMsg = {
        fileNotFoundError: new Error('cannot file in the path}'),
      };

And it will not return an error, but an object with one key named fileNotFoundError which is an Error.
Is it consistent with what fs returns on err?
I would expect it to be something like:

.rejects(new Error('foo bar'));

nit: emoty -> empty :)

Maybe I misunderstand you, but the test uses:

      const errorMsg = {
        fileNotFoundError: new Error('cannot file in the path}'),
      };

And it will not return an error, but an object with one key named fileNotFoundError which is an Error.
Is it consistent with what fs returns on err?
I would expect it to be something like:

.rejects(new Error('foo bar'));